home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part1 / 2925 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.6 KB
  1. Path: gryphon.phoenix.net!usenet
  2. From: "John F. Navratil" <jfn@phoenix.net>
  3. Newsgroups: comp.lang.c
  4. Subject: Re: Secure from Decompiling??
  5. Date: Wed, 24 Jan 1996 19:13:48 -0800
  6. Message-ID: <3106F56C.5D13@phoenix.net>
  7. References: <4djaq2$jd5@earth.superlink.net> <4e0e5iINN5qs@keats.ugrad.cs.ubc.ca>
  8. NNTP-Posting-Host: dial17.phoenix.net
  9. Mime-Version: 1.0
  10. Content-Type: text/plain; charset=us-ascii
  11. Content-Transfer-Encoding: 7bit
  12. X-Mailer: Mozilla 2.0b3 (Win16; I)
  13.  
  14. Kazimir Kylheku wrote:
  15. > 
  16. > In article <4djaq2$jd5@earth.superlink.net>,
  17. > Bob Stewart <rstewart@mars.superlink.net> wrote:
  18. > > I have a compiled C program containing a string that I want no one to
  19. > >be able to see, even with a decompiler.
  20. > >
  21. > >Is there any thing to put in the code that can prevent it from being
  22. > >decompiled, or make the decompiled code unintelligle??
  23. > 
  24. > Not possible. You can only make things tedious and difficult, but that will not
  25. > thwart a resourceful and sophisticated enemy.
  26. > 
  27. > You see, the code must always be intelligible to the CPU, and the actions of a
  28. > CPU are neatly deterministic.
  29. > 
  30. > Your program will, at some point, need to decrypt the string, and this
  31. > execution can be traced.
  32. > 
  33. > What you can do is never decrypt the string, but this is probably useless to
  34. > you :)
  35. > 
  36. > --
  37.  
  38.  
  39. True, no code can ever be indefinitely secure from cracking.  The 
  40. practical solution is to make it economically foolish to do so.
  41.  
  42. For example, battlefield commands must resist cracking for only the time 
  43. it takes to target the guns.  Once the first round is fired, the enemy 
  44. knows where you are shooting. In this case, a relatively inexpensive 
  45. coding can keep large resources busy for long enough to get the job done.
  46.  
  47. Banks must secure transactions for a slightly longer period of time.
  48.  
  49. You haven't said what the string is, but I assume it is some "key" which 
  50. matches some "lock" to protect unauthorized use of your program.  Your 
  51. task is to protect the key so that people will get it through an 
  52. authorized channel.  If the key is worth $20, all you have to do is put a 
  53. $21 hurdle in the way.  If the key is worth more, you must do more.  You 
  54. can easily detect simple tampering with CRCs, etc.  If you must transform 
  55. the key through some decryption process, do so in a way that the 
  56. decrypted key is never visible.  Maybe you should encrypt the lock.
  57. Look into trap-door functions which give you a many-to-one transformation 
  58. from free-text to encoded text.
  59.  
  60. Don't worry about someone breaking your code and reselling it.  It 
  61. requires many co-conspirators which are too easily detectable.
  62.  
  63. Cheers!
  64.  
  65. -- John
  66.